World-class support

How can we help you today?

More information:

babblevoice - Guide for your IT Department

This guide is for your IT department and aimed at answering any questions they may have in regards to how babblevoice fits in with your existing network.

Contents

Desktop

Babblevoice Desktop runs on users computers. It is a phone helper, designed to make using the phone and phone system simpler. Users, for example, can see colleagues on the phone, calls queueing in the queue, resolve calls to patients in EMIS and SystmOne amongst a host of other features.

Installing Desktop

We encourage Practice Managers to install babblevoice Desktop themselves. Please ensure they have all the relevant admin information to be able to do this. This is documented in the document 'babblevoice Installation Guide'.

Network Topology

Desktop is installed onto Surgery computers as detailed below.

The above diagram shows a typical surgery implementation. Phones are plugged into a dedicated network, separate from the surgeries own network (separated either physically or by VLANs). These phones talk directly with babblevoice SIP servers. See Network Topology Options for different scenarios.

The babblevoice Desktop, which is installed onto surgery computers, can perform 2 functions:

  1. A desktop tool, which offers click to dial of patient phone numbers stored in EMIS, and selecting patients records based on who you are on the phone with
  2. As an IVR which is capable of booking, cancelling, reminding appointments and checking in

For the purpose of the desktop functions, babblevoice Desktop receives caller id information so that the user can perform click to dial and other desktop functions. All information is communicated using either traditional HTTPS or HTTPS WebSockets.

Typical message sent to babblevoice Desktop:

{
            "type": "device",
            "device": "1001@bling.babblevoice.com",
            "state": "registered",
            "callcount": 1,
            "now":123456789,
            "calls": [
              {"uuid": "873265837658367", "direction": "inbound", "callid": "7887687-8775-6576576-767575", "callidname": "Some Name", "callstart": 123456776, "calledid": "01442299280", "calledidname": ""}
            ]
          }

Or

{
            "type": "queue",
            "queue": "test@bling.babblevoice.com",
            "waiting_count": 1,
            "talking_count": 0,
            "agent_count": 1,
            "now": 1369303228,
            "calls": [
              {"uuid": "e993ee38-c390-11e2-875b-cf8dc6d8088e", "callid": "01123456789", "callidname": "01123456789", "callstart": 1369303228}
            ]
          }

When a user wants to place a call or other action, it places a call to our API, as an example:

www.babblevoice.com/api/device/simplecall?d=1000@blilng.babblevoice.com&n=0123456789

When babblevoice Desktop operates in IVR mode, it acts as a 'bridge' which sits between EMIS Web (on the surgery site) and issues commands to babblevoice which actually handles the call.

When a call arrives which is intended for the IVR, babblevoice sends a message, similar to above which includes information to identify the call, including:

  • Caller ID
  • Called ID
  • UUID of the call

This allows babblevoice Desktop to handle the call and send back an xml document to instruct babblevoice on what to do, for example:

<?xml version="1.0" encoding="ISO-8859-1"?>
          <baaxml>
            <command>playspeak</command>
            <playspeak>
              <row><command>play</command><filename>yournextapp.wav</filename><alt>your next available appointment is on</alt></row>
              <row><command>speak</command><text>Monday the 4th of July</text></row>
            </playspeak>
            <getdigits><number>1</number><timeout>60</timeout></getdigits>
          </baaxml>

Using this mechanism, no clinical data is sent off the local network (nor the computer the software is running on).

Network

There are a number of different ways to configure the network to work with babblevoice. We have outlined 3 different architectures for the network. This caters for scenarios where HSCN is available or where it is not.

Firewall

Babblevoice requires a number of ports to be open through firewalls. Babblevoice Desktop usually just works as it only needs normal web traffic. Phones are more complex, so if you restrict traffic in and out of your site then this traffic needs enabling.

Recommended:

  • UDP Session Timeout - 300 seconds/5 minutes
  • TCP Session Timeout - 30 minutes
  • Disable SIP ALG on all network devices

If you fail to do this then phones may or may not work, or they may suffer with poor performance.

Phones

  • SIP (9997 UDP, 9997 & 9998 TCP)
  • RTP (UDP 10000 => 60000)
  • STUN (UDP/TCP 3478)
  • DNS (UDP/TCP 53)
  • NTP
  • HTTPS
  • HTTP

BV Desktop

  • HTTPS (including WebSocket)
  • HTTP
  • DNS (UDP/TCP 53)

If you intend to use BV Desktop as a phone, then the following is also required

  • STUN (UDP/TCP 3478)
  • RTP (UDP 10000 => 60000)

Depending on the network options (see below), this traffic may go over a HSCN firewall or the Babblevoice supplied firewall to be used with 3rd party broadband providers.

IP Addresses

If you control traffic by IP address then the following addresses should be added to your filter list. If you filter by IP address then please ensure you regularly check the Newsroom on our website for recent Product upgrades.

  • 109.169.89.208/28
  • 109.169.12.128/26
  • 217.147.95.240/28
  • 13.42.100.64/27
  • 54.76.182.113
  • 54.171.181.211
  • 18.200.220.239

Network Switches

The switches used for the voice network must deliver PoE 802.3af. Depending on the network chosen, the switches may also be required to be managed with VLAN capability.

Different mechanisms for ensuring quality can be achieved. If HSCN is used then the following is required when considering how to shape the traffic. Either QOS or shaping is acceptable.

Bandwidth

Information on bandwidth requirements can be found here. We recommend this document is reviewed.

Network Topology Options

Option 1 - Separate broadband, separate networks

This option keeps the 2 networks physically separate, both LAN and Internet connection. Babblevoice, typically, supplies the firewall, network switches and phones for the voice network. The surgery network remains untouched.

Option 2 - HSCN 2 physical LANs

In this option, the surgery network remains largely untouched. On the HSCN provision, one port is provided to the surgery network and a second port is provided for the voice network. DHCP would be required for the babblevoice network and should be provided by the HSCN Firewall.

DHCP would be required for the babblevoice network and should be provided by the HSCN Firewall.

Option 3 - HSCN VLANs

This scenario potentially saves cabling infrastructure in the building.

The Internet is supplied by HSCN which is similar to option 2. In this scenario, both voice and data traffic would be on the same physical network. There are two scenarios we can operate in.

  • VLANs are used to logically separate voice traffic from data - this can be done where physical phones are used.
  • Where softphones are used (for example for voice or video on the computer) then these cannot be separated out by VLANs but can be controlled if required at the firewall level.

DHCP would be required for the babblevoice network and should be provided by the HSCN Firewall.